【レポート】亀田さんトーク全文掲載！ “Amazon culture of Innovation とマイクロサービスアーキテクチャ” #AWSSummit

こんにちは HIRANO@おんせん県おおいた です。

Amazonのカルチャーを分かりやすく紹介していただく、AWSアドボケイトの亀田さん。今回も素晴らしい内容でした。 この感じを皆さんにお伝えする方法がないかと思い、全文文字起こししてみました。 少し長いですが、一読していただければと思います。

セッション概要

アマゾン ウェブ サービス ジャパン株式会社 シニアアドボケイト　亀田 治伸

このセッションでは、AWS そのものの開発を支える Amazon のカルチャーや組織の作り方のご紹介とともに、設計思想として用いられているマイクロサービスアーキテクチャーのご紹介を行います。また、巷でよく言われるアジャイル開発やドキュメンテーションサイクルとの完成についての考察もお話します。

レポート（全文掲載）

皆さんこんにちは。アマゾンウェブサービスジャパン、アドボケイトの亀田です。AWS Summit Online Tokyoにようこそ。今日私のセッションでは、アマゾンカルチャー、そして、アマゾンのイノベーションへの想い、それからAWSの開発を支えるマイクロサービスアーキテクチャについてお話をしていきたいと思います。

それでは早速本題に入ります。

スライドのタイトルですが、「Amazon Culture of Innovation とマイクロサービスアーキテクチャ」というタイトルになっています。

アマゾンは生まれながらにしてテクノロジカンパニーであると自分たちのことを考えています。まあ、一番最初は本の通販から始まったわけですが、あれは本を売りたくてamazon.comを立ち上げたわけではなく、インターネットというインフラに当時ファウンダーのJeff Bezosが注目をし、そのインターネットという新しいテクノロジーを駆使した新しいビジネスを展開することができるんじゃないかという検討を始めたのがきっかけになっています。

その中で、電子商取引に行き着いたわけですが、あの当時電子商取引自体のコンセプトがまだ成立するかどうかが分かりづらかった時代ですので、腐らない在庫ということでいろいろな検討した結果、本に行き着いています。

なおかつ、本というのは、ずっと倉庫に置いておくことができますし、模造品を作るコストも結構高いということで、実験的な電子商取引というものを試みるのに非常に適切であった、という背景があります。

従って、アマゾンはamazon.comの設立以降、AWSも含めてですけれども、最新のテクノロジーを駆使して色々なサービスを世の中に生み出していき、それをお客様の生活をちょっとずつ豊かなものにしていくことに挑戦している会社です。

今画面に出ている今日のアジェンダですけれども、まず最初にアマゾンカルチャーの話をさせていただきます。徹底した顧客志向の考え方、長期的思考の考え方、それから、失敗を恐れず失敗から学ぶというプロセスについてご紹介していきます。

Amazonのイノベーションの文化

徹底した顧客志向

まず1点目、徹底した顧客志向、お客様を全ての物事の起点にして、そこから逆算してサービスを開発していく、というやりかたを採用しています。我々は常に、サービスを開発する際に、お客様がそのサービスを使った際に、どのような体験をしていただくことができるのか、というものを定義してからサービスの開発を開始しています。

このように、お客様を中心としたアプローチというのは、単純に良いサービスが出来上がる、お客様に選ばれやすい、お客様満足度が高い、という話だけではなく、その他多くの利点がある、というふうに株主向けのレターで我々はお伝えしています。

それはどういったことかといいますと、人間の本質でもあるのですが、お客様というのは、常により良い何かを求めている存在であると考えています。時にはそれが、ありがたいことに、明確な明文化されたクレームとか要望というかたちで我々に頂くこともありますけれども、時にはそうではなく、何となく足りないという思いをお客様が抱えているケースもあります。

であれば、我々は、色々なリサーチや社内の検討にかける時間を極小化し、その分の時間をお客様との対話に多くの時間をさき、世の中のお客様に求められているサービスを開発していこうというアプローチをとっています。

また、このようなことも言っています。Jeff Bezosはamazon.comだけではなく、色々な投資も行っているわけですが、よく多くの人から「今後10年間何が変わりますか？」という話を聞かれるそうです。彼は、「今後10年間に何が変わらないか」を考える方が、より重要な知見を得られるのではなかろうか、といったことを言っています。

たとえば、ECサイトであれば、お客様はより早く、安く、より多くのものを欲している。クラウドコンピューティングであれば、同様に、お客様はより早く手に入るインフラ、安い、多くのテクノロジーを搭載している、こういったようなインフラを欲している、という要望についてはおそらく不変であるだろうと、10年、20年、100年経っても、この要望は存在しているはずです。不変の要望であれば、そこに対して戦略的に長期にわたる投資が可能となっていく、その実現手法がテクノロジーで進化していくだけである、といったようなことを言っています。

従って、まずサービス開発する際に、いったいお客様は何を求めているのか、というのをお客様との会話の中で特定し、そのサービスが出来たあとに、お客様がどのような体験をするのかというものをまず明確に定義するプロセスからサービス開発を始めています。

Working Backwards (お客様を起点に出発)

このプロセスを、アマゾン内部では、Working Backwardsというふうに読んでいます。まず、お客様との対話をもとに、お客様が困っていること、欲しいものを特定していきます。そこから、さらに、ビジネスのアイデアにつなげていくのですが、実際に開発に入る前に、サービスができたと仮定して、プレスリリース、それからそのプレスリリースを読んだ方からいただくであろう質問をまとめて、FAQというものを文書化します。関係者全員で、このプレスリリースおよびFAQの合意に至って、初めてサービス開発やマニュアルの作成といったものを作っていきます。

このプレスリリースというのは、サービスが出来た後に世の中に発表するために作るものではなく、一般的にプレスリリースという文章は、その会社が世の中に発表する最もシンプルな文書であり、なおかつ、社内事情が一切含まれていない文書になるわけですね。シンプルにお客様の体験をまとめている形態が、いわゆる一般的なプレスリリースになります。従って、我々はこれを一つの指標として作っている、ということをやっています。

Working Backwards ５つの質問

そのプレスリリースを書き上げる際、かならずこの５つの質問について回答を記載するルールになっています。 まず、「お客様はだれですか？」これは、B2Bのビジネスであれば、そこまでブレることはないですが、B2Cの場合はですね、かなりサービス開発の中でブレが関係者の中で生じていきます。たとえば、「若い男性」とか、「若い女性」とか、そいうったようなレベル感ではなく、もうすこしですね、どの地区に住んでいて、どういうライフスタイルを持っていて、結婚しているのかしていないのか、子供がいるのかいないのか、そういたようなかなり細かい特定をお客様として行います。 そのあと、お客様が抱えていらっしゃる課題ですね、「その課題を解決できる新しいチャンスは何ですか？」、なおかつ、「そのサービスを使ったときのお客様がうけるメリット」これが明確になっていますか？ それから、「どのようにしてお客様のニーズを知ったのですか？」これは逆の言い方をすると、お客様のニーズを知ったということは、お客様との接点ということになりますので、どのような接点でそのサービスを提供していくのですかと。 それから、最終的にお客様は、そのサービスを使うことで、日々の生活がどのように変わるかとかですね、そういう顧客体験が明確にまとまっているか、というのをプレスリリースの中にシンプルにまとめていくということになります。

Working Backwardsプロセスでの成果物

画面に出ているのはサンプルで、英語になっていますけど、当然関係者が全員日本人であれば日本語で作成します。プレスリリース書いた後、そのプレスリリースを関係者で回覧し、質問を取り寄せFAQをまとめあげていきます。FAQだけで質問の回答が明確にならない場合、まんが絵とか、ITのシステム系であればスクリーンショットをとって、実際のお客様の体験談をまとめていきます。

読んで、議論して、討議して、質問する

アマゾンの会議は沈黙から始まる、という話をみなさんお聞きになられたことがあるかもしれませんが、我々はこの手の文章を全てWord形式、PowerPointではなくWord形式で作成しているのですが、まず会議の始まりはこのWordをみんなで数分間、時には10分間程度時間をとって、沈黙の中読むところから会議を始めています。

これはなぜかというと、よくある会議の、事前に資料を送っておいて読んでおいてください、といったような会議というのは、関係者によって理解レベルがバラバラなところから会議が始まります。そうすると、会議の前半部分は、バラバラな知識を揃えるところに時間をとられてしまうので、結局、最初に読み込んできた人の時間努力が無駄になってしまうわけですね。仕事経験がない人であればあるほど、実際に資料を読んでなくても、それらしい答弁をするテクニックなんかも身につけていますので、そういう無駄が起きてしまうのであれば、会議の場所でまず全員が黙って文書を読む。読んだ後、積極的に矛盾点なんかをついて討論をしていく、というプロセスを経ています。

このプロセスは、アマゾンの全てのサービス開発や新しい試み、サービスの開発だけではなく、たとえばマーケティング部隊が新しいキャンペーンを行いたいとか、新しい広告、新しいブランドを立ち上げたい、そういった場合全てこのプロセスを経ています。

AWS誕生も Press Release, FAQから

実際にAWSそのものも、同じプロセスから生まれています。当時、Jeff Bezosのテクニカルアドバイザーだった人間が、APIベースでコンピュートリソースを操作できるものをサービスとして提供したらどうだろうという発案に至り、プレスリリースが作成されています。そのプレスリリースが合意するまでは、実はそれなりの時間をかけて検討されているのですが、60回程度関係者間のレビューを経て、プレスリリース、FAQがフィックスされ、その後に開発に入ったという歴史を持っています。

長期思考

（文化の）2点目が長期思考ですね。ものを開発していく、もしくは新しい物事を行うということは、すぐに結果が出ないものというのは当然存在しています。そのため、さっきお話しした通り、最終的なゴールを文章として正しくまとめて関係者が合意されているのであれば、途中に生じる色々な誤解とかですね、そういうものを恐れず物事を進めていこうといったところの考え方を持っています。

誤解を恐れない

新しいことや、革新的なことを始めるためには、時には周囲から誤解されることがありますが、そういったものを嫌がらずに物事を進めていこうと、その代わり最終ゴールは、可能な限りシンプル、かつ、お客様にとってメリットの高いゴールをきっちり設定しようという考え方です。

長期にわたる誤解と厭わない -kindle-

一例がこちらです。今このセッションをご覧の方もお持ちかもしれませんけども、kindleです。電子ブックですね。左側に出ているのは初代kindleです。私自身も、これはかなり前のハードウェアなので、実物を見たことは無いのですけれども、発売当初は世の中からかなり酷評されています。まず、そもそも分厚いので、非常に重たいんですね。なおかつ、容量も少ないので、持ち運べる、中に格納できる本の数も少ない。バックライトもないので、暗闇に入ると本が読めないとかですね、かなり酷評されています。今、我々は、ハードウェアの改善を続け、右のように非常にシンプルで、持ち運びやすい、本も数百冊入ります、使いやすいハードウェアまで進化させてきたのですが、この開発を途中でやめなかった、継続した理由は非常にシンプルです。

いかに頑張って物流を整備したとことで、世界中のユーザに１分で本を届けるというのは、やはり不可能なわけです。であれば、このようなデバイスがインターネットを経由して、電子的なデータとして本を受け取る、という手法は必ずお客様の体験を変えるはずだと、今のお客様のライフスタイルにとって、必ずプラスになるはずだ、そういう思いを持ってサービスの開発を継続していました。

AWSも当初は誤解された

実は、AWSも同じです。左側に出ているのは、Business Weekというアメリカの雑誌ですね。AWSは2006年3月にリリースしているのですが、その直後かなり酷評されています。「アマゾンの危険な賭け」というタイトルで雑誌が出ているんですけれども、とにかく「本屋アマゾンは何がしたいんだ？」と、果たしてそれが本当に売れると思っているのかと、そこに対してどれだけのお金をかけるつもりなのか、かなり言われています。

一方、我々は実現したい目標というものが存在していたので、そのような世の中の誤解に負けずに、サービスの開発を継続し、現在世界中で数百万、日本で数十万のお客様にご利用いただけるところまでAWSのサービスを続けてきました。

ここで実現したかったこと、非常にシンプルです。従来のITのインフラというのは、開発者がインフラの調達をする部隊に対して依頼を出し、構築が完了した後に作業を開始するというのが一般的でした。そこには、いろんな属人性も発生しますし、何より大量の待ち時間や、大量の初期費用が発生します。であれば、API経由で、いつでも必要なだけ確保できるITリソースサービスというものを作ることができれば、最終的には世の中の開発者に受け入れられるだろう、というシンプルな考え方です。これが、先ほど言ったプレスリリースやFAQにまとめられ、関係者間で合意し、開発がスタートした、最終目的になっています。

失敗を恐れず失敗から学ぶ

（文化の）3点目ですね、いかにお客様との対話に時間を割き、ビジョンがぶれないように文書作成に時間を割いたとしても、残念ながら失敗は起きます。アマゾンも、どちらかというと、失敗をいっぱい行っている部類の会社です。

ただ、我々は失敗をして責任を取らされるのではなく、失敗から得た学びを次につなげていこう、つまり積極的に失敗していこうといったことを考えています。

昨年Jeff Bezosがある場所で言った言葉があるのですけれども、今のamazon.comの規模であれば、何かを失敗するにしても数十億円規模の失敗をし、そこで得た学びというものを社内に蓄積していかないと、会社として全体として成長を維持していくのは難しい。こういったような考え方を話しています。

イノベーションのために失敗を受け入れる

これも株主様向けの文章の一部です。失敗をしているということは、新しいビジネスを模索しているということとイコールと我々は考えています。従って、アマゾンが数年間にわたって大きい失敗をしていない場合ですね、大きいビジネスへの投資をしていないとみなすことができますので、株主の方々は、我々が既に成立している事業の収益がどうやって成長しているかというのも当然大事だとは思うのですが、将来の成長といったことを考えた際に、今何をやろうとして、どういった失敗を繰り返しているのか、というものを見ていて欲しい、ということを株主の方にお伝えしています

失敗から学ぶ - Fire Phone -

今画面に出ているのは、現時点でアマゾン最大の失敗と言われているFire Phoneですね。日本でも発売していた時期ありましたけど、一年販売していないはずですね。非常に高機能だったのですが、お客様の生活にそんなに役に立つものではなかったという、残念な結果になっているのですが、失敗と発明は切っても切り離せないものだ、というふうに我々は考えています。 つまり、何かをやる前に、最初から成功すると分かっているのであれば、それは実験ではなくただの既存のビジネスの延長線であり、新しいのもやるのであれば、必ず失敗はつきまとうはすだ。従って、アマゾンは失敗した人間を責めるということは一切行わず、失敗した人間が文書の形式で、なぜ失敗したかという考察を関係者に正しく共有していくのであれば、失敗自体の責任を問わない、という仕組みを導入しています。

Amazon Echo

このハードウェアの開発で得られたノウハウです。残念ながらこのFire Phoneはうまくいかなかったわけですが、そのノウハウというのは、一部、たとえばAlexaですね、Amazon Echoなんかに引き継がれて、また次のビジネスの種になっている、ということになっています。

人事評価のシステム

それを支えている、アマゾン、AWSの人間に対する人事評価のシステムも、ちょっとユニークです。もともとチャレンジを前提として、これはサービス開発だけではなく、アマゾンで働いている社員全員が、何某かのチャレンジをすることを前提として、目標を設定しますので、1年間経って目標が100%成功しましたというのは論理的に考えづらい、という考え方です。その場合、年初に立てた目標を、ちょっと甘かった、ちょっと手を抜いた、いうような考え方をされます。

重視されるのは、目標を達成しようとするそのプロセスの中で、何を考えて、何を試してみて、それがうまくいったのか、うまくいかなかったのか、というのを文書の形式で作成し、関係者間に共有する、ということを徹底しています。ここのプロセスを正しくやっておけば、個別の失敗に関しては責任を問われない。というかたちになります。

Two-Way Door and One-Way Door

そこで密接に関連する考え方が、Two-Way Door、 One-Way Doorという考え方なのですけども、一般社員に訪れる日々の業務のほぼ全ての判断というのは、やり直しが可能です。当然、何かを実行する際の必要な検討を行うことも大事なのですが、そこに時間をかけすぎるのではなく、まずやってみて、そこで得た学びを改善につなげていこう。であれば、積極的にあまり考えることに時間を使いすぎるのではなく、積極的にまずやってみよう、という考え方です。

やったことを四半期ごとに、これもまたWordの文書の形で全社員がまとめて、関係者に報告して、次のステップを議論するということをやっています。

Narrative (文書) 文化

アマゾンの社内文書はPowerPointを使わないと聞いたことがある方もいらっしゃるかもしれませんが、基本的に全ての文書はWordで作成されます。関係者間で共有された後は、その作成者の個人の名前を消して、アマゾン内部の公式ドキュメントとしてノウハウを蓄積していくということをやっています。

なぜWordか？

まずPowerPointというのは、今日まさに私がこの講演で皆さんに見ていただいているPowerPointもそうですけれども、私が喋ることが前提で作られています。それは属人性を持ってしまうので、私自身が喋らなくなると、PowerPointだけみても全てが伝わらないわけですね。それでは、公式文書としてノウハウを社内に蓄積していくには足りませんので、本人がいなくても存続するようなWordの文書を使っています。

PowerPointはですね、話す人間のリズムとか、話し方とか、その人間が成功してきた人なのか、どうかで、聴く側の印象が変わってしまいます。ちょっとくらい論理破綻していても、リズムが良ければそれで受け入れらるケースなんかもあったりするのですが、そう言ったもの防ぐために、全社員が同じフォーマットでWordの文書をつくるということをやっています。

AWSの基本コンセプトとそれを支える開発スタイル

このプレスリリースやFAQなどを元に開発されたAWSですが、アマゾンのチャレンジ、イノベーションを起こすためのいろいろなサービス開発と切り離せない関係にあります。

AWSの基本コンセプトですが、必要な時に必要なだけ低価格で、初期費用が不要であり、完全従量課金、長期にわたる契約は不要ですので、必要な時に必要な分だけITのリソースをAPI経由で、待ち時間なしで開発者が手に入れることができる。つまり、大きい投資を伴わず、待ち時間が発生しない形で、やりたいことをやれる基盤をいつでも手に入れることができますので、積極的に色々なチャレンジをしていくことができるようになります。撤退コストがITインフラにおいてあらかじめ最小化されているという考え方です。

マイクロサービスアーキテクチャ

このAWSの開発そのものは、マイクロサービスアーキテクチャというアーキテクチャをベースとして、開発がされています。AWSだけではなく、今アマゾン全体でマイクロサービスアーキテクチャといったものを採用しています。このマイクロサービスアーキテクチャは別名Service Oriented Architectureとも言われます。複雑な巨大なアプリケーションをみんなで作っていくのではなく、一つのアプリケーションには一つの目的だけしか持たさないようにしよう。そして、複数のアプリケーションは、APIでのみ連携させていこう、という考え方です。 APIでのみシステムが連携されるのであれば、お互いがブラックボックスでも、同時並行で開発が継続できるというメリットがあります。

たとえば、向こうがLinux、こっちがWindows,向こうがOracle、こっちがMySQL、でも関係なく、APIでしか連携しない状態でサービスを開発していこうという考え方です。

モノリシックアーキテクチャ

これにはいくつかのメリットがあります。 まず、それの対極にあるのがモノリシックアーキテクチャと言われるものです。

昨今、クラウドネイティブ開発の文脈の中で、このモノリシックアーキテクチャは悪者にされがちですが、いつなんどきモノリシックアーキテクチャがダメだというわけではないです。モノリシックアーキテクチャは一つの堅牢な巨大なシステムを複数人で頑張って作っていこうという考え方です。複数人というか複数チームですね。

ビジネスの初期状態は非常にメンテナンスがしやすいです。なぜなら、アプリケーションが１個になります。一人の人間が全てを把握しやすい規模感であれば、非常にメンテナンスがしやすいわけです。

一方、ビジネスがどんどん拡張していくと、色々な機能が後から付け足されていくことになりますので、中身は相当密結合状態になります。そのうち一人の人間が理解できる物理限界を超えたアプリケーションが成長していきますので、どこを触るとどこに影響が出るかがだんだん分かりづらくなってきます。当然メンテナンスにも時間がかかりますし、新しいモジュールの投入やテストも、関係者が増える一方どんどん時間がかかるといったような現象が発生します。

システム 組織 特異点が発生

この現象を長時間放置したままみんなで頑張ってメンテナンスを続けると、次に組織的な問題が絡んできます。一人の人間が全てを理解することが困難になっている状態であれば、必然的に長い間その組織にいる古株の方に判断権限が集中していきます。

つまり、新しいことをやろうとした際や、外部から中途社員が入ってきたときや、新入社員が新しく配属されても、自分たちがやりたいことが自由にやれないという状態になります。古い方、権限を持っている方が、「いいよ」と言わないと何もできないといったような、組織的な属人性が伴ってきます。

実は2000年頭にamazon.comも同じ問題を抱えていて、ECサイト自体のビジネスの成長を阻害する要因になりはじめていました。そこで、アプリケーションの開発方式をすべてマイクロサービスアーキテクチャ、単一のアプリケーションには１個の目的しか持たせない、そしてそのアプリケーションごとに責任を持つチームを作っていく、というやり方に変えています。

Two-Pizza Teams

アマゾンではTwo-Pizza Teamsという言い方をするのですが、２枚のピザでちょうどお腹一杯になるくらいの人数をチームの上限にしましょう、という考え方です。これはアメリカのピザの話なので、みなさんが思っているより若干人数か多いです。7〜10名くらいと言われています。

なぜかというと、日本だろうがアメリカだろうが、人が増えれば増えるほど属人性が出てしまうので、それは避けられないわけですね。であれば、そこを極小化しておきましょうと。10名であれば10名の中での調整はどうせ発生はするわけですけれども、そこの人数を不安をやめましょうという考え方です。

IT業界にはコンウェイの法則という言葉がありますけれども、ある組織が作るアプリケーションは、おおよそその組織の形を反映したものが出来上がってくるという法則があります。従って、マイクロサービスアーキテクチャを採用する際は、小さいチームをアプリケーションごとに作り、権限を移譲していく、といったことを同時にやる必要があります。

AWSの場合はこのTwo-Pizza Teams一個一個がAWSのサービス一個一個に責任を持っているのですが、その責任範囲は非常に権限委譲されており、幅広いです。サービスのロードマップの策定、マニュアル、APIドキュメントの策定、サポート業務、収益の責任、当然アプリケーションの開発そのもの。たった7名から10名のチームで、多くのものの責任を持っているんですね。

結果として、必然的に、従来のプロマネ、SE、プログラマといった垣根が無くなっていきます。一人ひとりの人間がなるべく多くの役割を複数同時にこなしていくという考え方です。

イベントドリブン

その結果として生み出されるAWSの各コンポーネントは、マイクロサービスアーキテクチャに支えられているわけですが、図にするとこんな感じです。各サービスがAPI経由で連携していくのですが、画面に「イベント」という記載があります。イベントドリブンというのもマイクロサービスアーキテクチャの中で非常に重要な考え方です。

イベントというのは、何か他のアプリケーションと連携したいタイミングになった時点で、初めて相手を呼び出してください、単純にいうとそういう考え方ですね。

なので、せっかくマイクロサービスアーキテクチャを採用しているにもかかわらず、WebSocketとかでセッションを張り続けたりしているとか、アプリケーションAが朝2:00までにここにCSVファイルを置いておくのでアプリケーションBは2:10にこのファイルを持っていく、みたいな連携をさせると相手側の障害が逆側に影響を与えるわけですね。

そういった連携経路を作るのではなく、なるべくイベントドリブンでAPIコールをしていくというのが、マイクロサービスアーキテクチャの基本的な考え方です。

クラウドネイティブ開発だからアジャイルで？

クラウド上でマイクロサービスアーキテクチャを採用した開発をよくクラウドネイティブ開発と言われます。クラウドネイティブ開発というのは、アジャイル開発と相性が良いわけですけど、時にこう言ったような言われ方をするケースがあります。

アジャイル開発をするのであればドキュメントは後回しで、先にどんどんリリースをしていこうと。エンジニアの時間を、ドキュメント制作ではなく、リリースの方により時間を使っていこうと、といったような考え方をされるケースがあります。

ここにはマイクロサービスアーキテクチャに対する大きな誤解が存在しているので、このセッションの残りの時間でそれについてお伝えします。

アジャイルソフトウェア開発宣言

まず、アジャイル開発には、土台となる「アジャイルソフトウェア開発宣言」があります。この画像は、その「アジャイルソフトウェア開発宣言」の日本語版のホームページからお借りしていますが、上から２行目ですね。「包括的なドキュメントよりも動くソフトウェアを」という記載があります。

お客様にとって、そちらの方がメリットが高いのであれば、包括的なドキュメントに時間を使うよりも、動くソフトウェアのリリースに集中していこうという考え方です。

非常に大事な点ですが、お客様にとってメリットが高いのであれば、従来のウォーターフォール型のやり方を変えていってもいいじゃないかという考え方が、このアジャイルソフトウェア開発宣言になっています。

Microservice/アジャイル開発とドキュメンテーション

この考え方をベースにもう一度、先ほど私が説明したマイクロサービスとアジャイル開発、それからドキュメンテーション関係性を見ていきたいと思います。

マイクロサービスとAPI

マイクロサービスというのは、個別のアプリケーションがAPI経由で連携していくことが、そのミソになっています。API連携で複数のアプリケーションが疎結合型で有機的に結合している状態を作り出す。つまりAPIを使う存在は社内の別の開発部隊であれ、お客様であれ、そのチームにとって全てお客様という考え方です。

たとえば、AWSの場合は、各サービスに責任を持っているTwo-Pizza Teamsはかなり権限委譲されているので、自分達の判断だけでリリースを行なっています。２つのチームが、定例会を行なって何かを調整するとか、その上にマネージャーを設けてお互いの利害を調整するとか、そういったようなことを可能な限りしないようにAWSは開発されています。

つまりAWSのサービスを開発をする人たちからすると、そのAPIを使うのは他のAWSの部隊であれ、みなさんであれ、日本のAWSの社員であれ、全てお客様という考え方です。

となると、やはり、APIの仕様はドキュメント通りに必ず動く必要があるので、先にリリースをするということは実は許されないわけです。AWS実際に使っている方はご存知だと思いますけども、新しいサービスがリリースした時、もしくは既存のサービスがバージョンアップして新しいAPIができた時、必ずその時点でドキュメントが存在しています。日本語化が間に合っていないケースというのは、申し訳ないのですが、残念ながら存在しているのですけれども、最低限英語のドキュメントがリリースされたあとに、APIがリリースされる、という順序をとっています。

従って、本来マイクロサービスアーキテクチャを正しく回すのであれば、APIの改修や新規リリースは、ウォーターフォールに近い状態になります。一方ちょっとした中身の改修ですね、アルゴリズムを良くしたり、実行速度を早くしたり、そう言ったようなものはドキュメントに影響与えませんので、一部内部でリリースしているケースはあるかと思いますけども、大きいリリース、サービスの仕様変更、新しいサービスのリリースなんかはウォーターフォールになっています。ウォータフォールに近しい状態になっていると行った方がよろしいですかね。

じゃあ、なんでマイクロサービスやクラウドネイティブ開発とアジャイルが相性が良いと思われているかということなんですが、AWSは現在190を超えるサービスが存在しています。

と、いうことは・・・？　つまり

そのサービスそれぞれに、マイクロサービスに責任を持っているチームが存在している、という考えなんですね。そのチームが独自の判断で、アプリケーション開発して、バージョンアップしていく。

AWSという存在を上から見ると、常にAWSのどこかで局地的にアプリケーションがバージョンアップしている、という状態であることが分かります。一方、AWSの開発の順番を整理したり、そういったような制御を行っていないので、AWS全体としてサービスを見ると、確かにアジャイル開発っぽく、いろんなところで、いろんなリリースが日々されるようになっているのですが、それは結果として、各小さいウォーターフォールのスプリントの集合体がAWSを形作っているということになります。

この状態を作り出すのに必要なものとしては、当然チームの分割と権限委譲になっています。

よく、日本のお客様との会話の中で、マイクロサービスやってみたんだけど、手間ばっか増えてくと、マイクロサービスというのは、アプリケーションの数がどんどん増えていってしまうので、管理工数が増えるというデメリットがあるというのは事実ですね。デメリットよりメリットの方が多いという考え方ですけれども、手間ばっか増えてしまったというケースがけっこうあります。

これなぜかというと、こういったものを統合で取りまとめようとする存在を作ったり、組織への権限委譲が正しくできていなかったりすると、中途半端な状態でマイクロサービスのデメリットばかりが先行してしまう、そういった考え方になりますので、ぜひアプリケーションアーキテクチャの話だけでなく、組織分割と権限委譲をセットで検討していただければ、いいんじゃないかなと思います。

それから、このマイクロサービスアーキテクチャは、イノベーションともう一つ密接な関係を持っています。何か新しいことをやる際に、マイクロサービスアーキテクチャを採用しておくと、疎結合方になりますので、その部分を非常に切り離しやすいという特性があります。アプリケーションを切り離すことも簡単ですし、チームそのものを移動させることも非常に簡単になるので、より積極的に新しいことに挑戦していけるようになっていきます。

Thank you!

私のセッションは以上になります。 皆さんのアプリケーション開発、クラウドネイティブ開発に、何かの参考になれば幸いです。 どうもありがとうございました。

まとめ

いかがでしたでしょうか。亀田さんのトークの雰囲気（亀田節）が少しでも伝わっていれば幸いです。

アマゾンカルチャーのお話は亀田さんの定番ですが、今回のセッションはさらに成熟されていて、この雰囲気をなんとか伝えたいと思い、全文文字起こししてみました。

もしご興味が湧きましたら、下記よりセッション動画をご覧ください。

動画と資料

セッションの動画と資料はこちら